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Abstract 

We demonstrate the pragmatic value of the principal typing property, 
a property more general than ML's principal type property, by study- 
ing a type system with principal typings. The type system is based on 
rank 2 intersection types and is closely related to ML. Its principal typ- 
ing property provides elegant support for separate compilation, including 
"smartest recompilation" and incremental type inference, and for accurate 
type error messages. Moreover, it motivates a novel rule for typing recur- 
sive definitions that can type many examples of polymorphic recursion. 
Type inference remains decidable; this is surprising, since type inference 
for ML plus polymorphic recursion is undecidable. 

Keywords: Polymorphic recursion, separate compilation, incremental 
type inference, error messages, intersection types. 



1 Introduction 

We would like to make a careful distinction between the following two properties 
of type systems. 

Property A 

Given: a term M typable in type environment A. 
There exists: a type a representing all possible types for M in A. 

Property B 

Given: a typable term M . 
There exists: a typing A\- M : a representing all possible typings of M . 
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Property A is the familiar principal type property of ML. By analogy, we will 
call Property B the principal typing property. The names are close enough to 
give us pause. In fact, some authors have used "principal typings" in reference 
to Property A. But "principal typings" is also the name traditionally applied 
to Property B, and we will not introduce a new name here. 

Why do we care to make such a distinction? Property A — principal types — 
is certainly useful. But Property B — principal typings — is more useful still. 
We believe this has been overlooked because ML and its extensions completely 
dominate current research on type inference; and we know of no sense in which 
ML has principal typings. We will return to this point in §6. 

In this paper, we demonstrate the usefulness of the principal typing property 
by studying a type system that has it. We emphasize that our results are 
motivated entirely by the general principal typing property, and not by the 
technical details of this particular case study. Any system with principal typings 
can benefit from our observations. 

Nevertheless, we take some care in choosing our case study, so that its rel- 
evance to current practice will be immediately evident. Therefore, we seek a 
type system closely related to ML: it should be able to type all ML programs, 
it should have decidable type inference, and the complexity of type inference 
should be approximately the same as in ML. 

The type system that satisfies all of these requirements is the system of 
rank 2 intersection types. This system is closely related to the more well-known 
rank 2 of System F — they type exactly the same terms — but it possesses the 
additional property of principal typings. We use a variant of this system, called 
P2, as our case study. 

The distinction between principal types and principal typings is evident in 
the type inference algorithm for P2: it takes a single input, a term M , and 
produces two outputs, an A and a such that A h M : a. The types required 
of the free variables of M are specified by A; but A is a byproduct of type 
inference, not a necessary input. Contrast this with Milner's algorithm for ML, 
whose let-polymorphism relies on A being an input. 

We illustrate the benefits of principal typings in three areas: recursive defi- 
nitions, separate compilation, and accurate type error messages. 

Recursive definitions. The following well-known example was used by 
Mycroft [17] to illustrate the deficiencies of ML's handling of recursive defini- 
tions: 

map = Xf.Xl. if null I then nil else f(hd I) :: map f (tl I) 

squarelist = XL map (Xx. x x x) I 
complement = XI. map (Xx. not x) I 

This program is not typable in ML when presented as a single, mutually recur- 
sive definition. 1 The rule of polymorphic recursion was introduced [17, 10] as a 



Note that map does not depend on the other functions, and it is possible for ML to type 
the program by considering the definition of map separately; but Mycroft exhibits natural 



remedy: 

, N A x U \x : a} h M : a , , . „ x , N 

(REC-POLYJ r_ , tit-. (where a is an ML type scheme) 

The rule (rec-POLy) allows the body M of the recursive definition (jixM) to be 
typed under the assumption that x has a polymorphic type. This is sufficient to 
handle the map example above. But now consider type inference using Milner's 
algorithm: in order to infer a type, a, for the definition M , we need to know 
the type to use for the free variable x, that is, a. Resolution of this "chicken 
and egg" problem is, in fact, impossible: type inference is undecidable [11, 5]. 

The principal typing property suggests a new rule for typing recursive defi- 
nitions: 

A x U{x :t}\~ M : a 



A h {jixM) : a 



(where a < r) 



In this rule, the type r assumed for the recursive variable x need not be the same 
as the type a derived for its definition M . The type r expresses the requirements 
on x needed to give M the type a; as long as a meets these requirements (a < r), 
it is safe to assume it as the type of the definition. 

Now the strategy for type inference becomes clear: infer the principal typing 
A \~ M : a for M , producing both a and r = A(x). It only remains to ensure 
a < r, and this can be accomplished by subtype satisfaction, a procedure similar 
to unification. The result is a type system with decidable type inference, able 
to type many examples of polymorphic recursion, including the map example. 

Separate compilation. In separate compilation, a large program is divided 
into smaller modules, each of which is type checked and compiled in isolation. 
The program as a whole is closed, but modules have free variables — a module 
may refer to other modules. Types play an important role in compilation; for 
instance, the data representations and calling conventions of a module may 
depend on its type. Thus the compiled machine code of a module may depend 
on the types of external variables that it references. 

Consequently, most compilers require the user to specify the types of ex- 
ternal variables referenced in each module. In P2, our ability to perform type 
inference on program fragments with free variables means that the user need 
not write these specifications: the compiler can infer them itself. More signif- 
icantly, principal typings will enable us to achieve smartest recompilation [18], 
which guarantees that a module need not be recompiled unless its own defini- 
tion changes. We also show that principal typings enable an elegant and efficient 
solution to a related problem, incremental type inference [1]. 

Error messages. Most compilers for strongly typed languages do not do a 
good job of pinpointing the location of type errors in programs; see Wand [21] 
for a discussion. As a final example of the utility of principal typings, we show 



examples of functions that cannot be separated in this manner, and which cannot be typed 
in ML. 



that principal typings help to produce error messages that accurately identify 
the source of type errors. 

Organization of the paper. We introduce the type system P2 in §2, and 
state some of its basic properties. We describe how we type recursive definitions 
in §3, and we show how principal typings support separate compilation in §4. 
We describe how principal typings produce more accurate type error messages 
in §5. In §6, we address the question of whether principal typings exist for ML. 
In §7, we describe an extension of P2 with principal typings. We discuss related 
work in §8, and we summarize our results in §9. In an appendix, we show how 
our rule for typing recursive definitions could be added to ML. Proofs of all 
theorems can be found in a separate paper [6]. 

2 The type system 

We now present our type system, in an expository manner. Uninteresting details 
have been placed in an appendix. For the most part, the system relies on 
familiar rules of subtyping and type assignment. However, the system is based 
on a notion of rank, and there are some complications due to the need to stay 
within rank. These complications are characteristic of all ranked systems. 
Our programs are just the terms of the lambda calculus: 

M ::= x\ (M 1 M 2 ) \ (XxM). 

Notice that our programs do not use ML's let-expressions. In our type system, 
let x = M in N can be considered an abbreviation for (XxN)M . 

We will be defining several classes of types, each of which is a restriction of 
the types with quantification and intersection: 

a ::= t | (<n -► <r 2 ) | (Vi<r) | (<n A a 2 ). 

For those unfamiliar with intersection types, we present a brief example. A 
term of type (a At) is thought of as having both the type a and the type r. For 
example, the identity function has both type (t —> t) and (s — ► s) — ► (s — ► s), so 

(Xy.y) :(t^t)A((s^s)^(s^s)). 

By this intuition, a quantified type stands for the infinite intersection of its 
instances: 

(Xy.y) : (iu.u^ u). 

The types (t — ► t) and (s — ► s) — ► (s — ► s) are instances of (Mu.u — ► u), so in 
some sense this typing is "more general" than the first. 

Our ranked system will allow only a limited use of intersections: they may 
only appear to the left of a single arrow. For example, we will be able to derive 
the following type in our system: 

(Xx.xx) : V 's ,t .(s A (s — ► t)) — ► t. 



This says that as long as the argument of the function (Xx.xx) has both the 
types s and s —>■ t, for some s and t, the result will be of type t. Note that this 
term is not typable in ML. An appropriate argument for this function is the 
identity function: 

(Xx.xx)(Xy.y) : (Vw.w — ► u). 

Again, we will be able to derive this type in our system. This example is typable 
in ML, provided it is translated into a let-expression: 

let x = (Xy.y) in xx : (Vw.w — ► u). 

We now give the details of our ranked system, called P2. The sets To, Ti, 
T2, and T\/2 of types are defined inductively by the equations below. 

To = { t I t is a type variable } U {(a —>■ t) \ a, r £ To}, 

Ti = T U {((7 At) |<7,rGTi}, 

T 2 = ToU{(<7^r)|<7eTi,reT 2 }, 

T V2 = T 2 U{(Vt(T) |<t£Tv2}. 

The set To is the set of simple types, and Ti is the set of finite, nonempty 
intersections of simple types. T 2 is the set of rank 2 intersection types: these 
are types possibly containing intersections, but only to the left of a single arrow. 
Note that To = Ti l~l T 2 . Finally, Ty 2 adds top-level quantification of type 
variables to T 2 . 

Just as we have several classes of types, we have several subtyping relations. 2 
Their definition is simplified by observing the following conventions: we con- 
sider types to be syntactically equal modulo renaming of bound type variables, 
reordering of adjacent quantifiers, and elimination of unnecessary quantifiers; 
and we consider 'A' to be an associative, commutative, and idempotent oper- 
ator, so that any Ti type may be considered a finite, nonempty set of simple 
types, written in the form (/\ ieI (Ti), where each o - ; £ To. 

Definition 1 For i £ {1,2,V2}, we define the relation <; as the least partial 
order on T; closed under the following rules: 

• H {tj I J e J} C {<n I i £ /}, then (J\ ieI (n) <! (A ieJ tj). 

• If <7i <i t± and r 2 < 2 a 2 , then (n —>■ r 2 ) < 2 (yi —>■ a 2 ). 

• If a <2 t, then a <y 2 t. 

• If t £ T , then (Mta) < V2 {t := r}a. 

• If a <y 2 t and t is not free in a, then a <y 2 (Vtr). 



These could be combined into a single subtyping relation, but it is technically convenient 
to keep them separate. 



The first rule says that <i expresses the natural ordering on intersection types. 
The second rule says that <2 obeys the usual antimonotonic ordering on function 
types, restricted to rank 2. The rules for <\/2 express the intuition that a type 
is a subtype of its instances (we write {t := r}<7 for the substitution of r for t 
in a). They are equivalent to the following rule, similar to ML's notion of 
generic instance: 

• If {<T := pja < 2 r, where p is a vector of simple types, and the type 
variables t are not free in (Vsu), then Vs<7 <\/2 Vtr. 

Note that we only allow instantiation of simple types. This ensures that instanti- 
ation does not take us beyond rank 2. It also has less desirable implications, e.g., 
(yt.t) is not a least type in the ordering <\/2^ (Vt.t) ^\/2 («i A (si — ► S2)) —> «2- 
A fourth subtyping relation will play an important role in the type system. 
The relation <\/2,i between TV2 and Ti is the smallest relation satisfying the 
rule: 

• If a <V2 n for all i £ I, then a <v2,i (Aiei T i)- 

The relation <\/2,i is not a partial order; it is not even reflexive. This is because 
it relates types "across rank." Note that in a comparison 



(Vt<7)<v2,i(/\r,-), 



iei 



the type variable t may be instantiated differently for each T£. 

The type system derives judgments of the form A\- M : a, where a is a TV2 
type, and all of the types in A are Ti types. The typing rules are given below. 

(where a <i r £ To) 



(where a <\/2,i T\) 
(where t is not free in A) 
(where r <\/2 c) 



Example 2 Recall that the typings 

(Xx.xx) : Vs, t.(s A (s — ► t)) —> t, 
(Xy.y) : (Vu.u -> u), 

hold in our system. Then by rule (sub), 

(Xx.xx) : (s — ► s) A ((s — ► s) — ► (s — ► s)) —> (s — ► s). 
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(var) 


A U {x : a} h x : r 


(abs) 


A^ U {« : u} h M : r 


A h (AzM) : cr -► r 


(app) 


i h M : ri ^ t 2 A h # : <r 


A h (M#) : r 2 


(gen) 


Ah M : cr 


A h M : (Vtcr) 


(sub) 


Ah M : r 
Ah M : a 



And (Vm.m — ► u) <\/2,i (s — > s) A ((s — ► s) — ► (s — ► s)), so by rule (app), 

(Xx.xx)(Xy.y) : (s — ► s). 
Finally, by rule (gen), 

(Xx.xx)(Xy.y) : Vs.s — ► s. 
We now give the definition of principal typings appropriate to our system. 

Definition 3 

i) A typing B h M : r is an instance of a typing A h M : a if there 
is a substitution 5 such that Sa <\/2 i" and 5(a;) <i S(A(x)) for all 
a; G dom(A). 

ii) A principal typing for a term M is a typing A h M : c of which any other 
typing of M is an instance. 

This definition is standard, c.f. [16]. Note in particular that the notion of in- 
stance is monotonic in the derived type, but antimonotonic in the type environ- 
ment. The intuition is, a principal typing EXPECTS LESS of its free variables, 
and PROVIDES MORE than any other typing judgment. 

The close connection between all of the rank 2 systems is expressed by the 
following theorem. 

Theorem 4 A term M is typable in P2 iff M is typable in rank 2 of System F 
iff M is typable in rank 2 of the intersection type discipline. Therefore, typability 
in P 2 is DEXPTIME-complete. 

The equivalence between rank 2 of System F and the rank 2 intersection disci- 
pline has been shown independently by Yokouchi [23]. 

2.1 Subtype satisfaction 

In order to perform type inference, we must solve subtype satisfaction problems, 
which generalize unification. Solving subtype satisfaction also gives a decision 
procedure for subtyping. We will focus on the relation <v2,i, as it is the most 
important for type inference; all of the other relations can be handled in a 
similar manner. 

A <\/2,\-satisfaction problem tt is a pair 3s. P, where P is a set whose every 
element is either: 1) an equality between simple types; or 2) an inequality 
between a TV2 type and a Ti type. A substitution S is a solution to 3s. P if 
there is a substitution 5" such that S(t) = S'(t) for all t ^ s, S'a <\/2,i S't 
for all inequalities (a < r) G P, and S'a = S't for all equalities (a = r) £ P. 
We write MGS(-7r) for the set of most general solutions to a <\/2,i-satisfaction 
problem 7r (as with unification, most general solutions are not unique). 

Theorem 5 

i) The relation <\/2,i is decidable. 



ii) If a <y 2 ^-satisfaction problem tt is solvable, then there is a most general 
solution for ir. Moreover, there is an algorithm that decides, for any tt, 
whether tt is solvable, and, if so, returns a most general solution. 

Algorithms for deciding <\/2,i subtyping and solving <\/2,i-satisfaction prob- 
lems are given in Appendix B. 

2.2 Type inference 

The type inference algorithm is presented in the style favored by the intersection 
type community: for any M , we define a set, PP(M), called the principal pairs 
of M. Every element of PP(M) is a pair (A, a) such that A h M : a is a 
principal typing of M . 

The following technical property is used to show that PP(M) indeed specifies 
a type inference algorithm: the set PP(M) is an equivalence class of pairs under 
permutations, i.e., {A\, a-\), (A2, 12} £ PP(M) iff {A\, a-\) = S{A2, (T2) for some 
bijection S of type variables. Therefore, in choosing (A, a) £ PP(M) it is always 
possible to guarantee that the type variables of (A, a) are "fresh". 

To perform type inference, simply follow the definition of PP(M), choosing 
"fresh" type variables and using the MGS algorithm as necessary. 

Definition 6 For any term M , the set PP(M) is defined by the following rules. 

• If M = x, then for any type variable t, ({x : t},t) £ PP(A). 

• If M = XxN, and (A,Vs<7) £ PP(A), where the type variables s are 
distinct from all other type variables, then: 

i) If x ^ dom(A), and t is a type variable not appearing in (A,Vs(t}, 
then (A,Vts(t -+ a)) £ PP(XxN). 

ii) lixe dom(A), then (A x , Gen(A x , A(x) -+ a)) £ PP(XxN). 

• If M = M 1 M 2 , the type variables of (Ai, Vsui) £ PP(Mi) and (A 2 , a 2 ) £ 
PP(M2) are disjoint, and the type variables s are distinct from all other 
type variables: 

i) If <T\ is a type variable t, t\ and ^2 are fresh type variables, U £ 
MGS({cr 2 < ti,t = ti -^t 2 }), and A= U(A 1 + A 2 ), then 

(A, Gen( A, Ut 2 )} £ PP(M). 

ii) If ai = n -^ r 2 , U £ MGS({cr 2 < n}), and A = U(A 1 + A 2 ), then 
(A,Gen(A,?7r2)) ePP(M). 

Example 7 We show how the algorithm finds the type of (Xx.xx). 
i) PP(A) produces a pair ({x : ti } , ii) . 
ii) PP(a;) (again) produces a pair ({x : <2}j ^2}- 
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iii) To calculate PP(m), we find a most general solution to 

{^2 < ^3, ti = ^3 — ► ^4}, 
such as {^2 := ^3, t\ '■= ^3 —> ^4}- Then ({x : ts A (ts — ► £4)}, £4} G PP(xx). 
iv) Finally, PP(Xx.xx) produces (0, Vt3, £4.^3 A (£3 —> £4) —> £4}. 

Theorem 8 (Principal typings) If M is typable in P2, then there is a pair 
(A, a) G PP(M) such that A\- M : a is a principal typing for M . 

3 Recursive definitions 

We now add recursive definitions to our language. A term of the form (jixM) 
is meant to represent the program x such that x = M , where M may contain 
occurrences of x. The following rule is a straightforward way to type such 
definitions, and is the rule adopted by ML: 

, N A x U \x : a} h M : a . . . . . ; N 

(REC-SIMPLEJ ' , tit-. (where a is a simple type) 

As remarked in the introduction, this simple recursion is not able to type the 
map example, and other examples of interest. And the rule (rec-POLy) is not 
appropriate for our system, because we do not allow quantified types in our type 
environments. 

Instead, we propose the following rules for typing recursive definitions: 

, , A x U {x : t] h M : a , . „ , 

( REC ) A h ( P xM) : a (where . < V2ll r) 

/ x A x \- M : a , , . . „ ^ 

(REC-VAC) — -r-. — -, —; (where x is not free in M) 

v ' A\~ {jixM) : a v ' 

The rule (rec-VAc) is necessary to type terms like 

(jjlw(\x.xx)) : Vs,t.(s A (s — ► t)) —> t. 

In order to use the rule (rec) in this case, we would need a type r G Ti such 
that Vs, t.(s A (s —>■ t)) —>■ t <\/2,i t. There is no such type, because s and s —>■ t 
cannot be unified. 

The rules (rec) and (rec-VAc) can type strictly more terms than (rec- 
simple), but not as many terms as (rec-poly). 

Example 9 

i) The following term is typable in P 2 + (rec) + (rec-VAc), but not in 
P 2 + (rec-simple): 

(jjlx .(\yz .z)(xx) : Vt.t — ► t. 

The self-application xx cannot be typed if x is assigned just a simple type. 
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ii) The term {jix.xx) is typable in ML+ (rec-poly) , but not in P 2 + (rec)- 
(rec-vac). In ML + (rec-poly) it has type (\ft.t). 

Now we add mutually recursive definitions to the language: 

(letrec x\ = M\, . . . ,x n = M n in M), 

where all of the X{ are distinct. The corresponding typing rule is: 



(letrec) 



A Xl ... Xn U {xi : Ti, ...,x n : r n } h M : a 
(Vi < n) A Xl ... Xn U {xi :ti,...,x„ : t„} \- (jjxjMj) : <Jj 
A h (letrec x x = Mi , . . . , x n = M n in M) : a 

(where Mi < n, &{ <\/2,i Ti) 



In the hypothesis of this rule, we are careful to type each definition Mi as a 
recursive but not mutually recursive definition. Thus at first, each Mi needs to 
satisfy only the constraints on x, implied by the occurrences of x, in Mi itself; 
constraints implied by occurrences in M or other Mj are satisfied second. In 
between, the type of Mi can be generalized. 

This is the technical trick that lets us type examples like map. Even when 
we are presented with map, squarelist, and complement in a mutually recursive 
definition, we will type each of them first without mutual recursion. 

Example 10 Let M m , M s , and M c abbreviate the definitions of map, squarelist, 
and complement, and let 

A = {map : ((int — ► int) — ► int list — ► int list) 

A ((bool — ► bool) — ► bool list —> bool list)}. 

Since 

A \~ (jimap .M m ) : Vs, t.(s —> t) —> s list -^ t list, 

A \~ (jjLsquarelist.M s ) : int list — ► int list, 

A \~ (ji complement .M c ) : bool list — ► bool list, 

and (is,t.(s —> t) —> s list -^ t list) <\/2,i A(map), by rule (letrec) the term 

(letrec map = M m , 

squarelist = M s , 

complement = M c 
in 0) 

is typable. 

Adding the following clauses to Definition 6 gives a type inference algorithm. 

• If M = (iixN) and {A, a) E PP(#), then: 

i) If x <£ dom(,4), then {A, a) E PP(M). 
ii) ItxE dom(,4) and U E MGS({<7 < V2 ,i A(x)}), 
then {UA x ,Gen(UA x ,Ua)} £ PP(M). 
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• If M = (letrec x x = M x , . . . , x n = M n in M ), 

and (Ai,<7i) £ PP(//a;;M;) for 1 < i < n, 

(Ao,<7 }ePP(Mo), 

A' = A + Si<j'< nJ 4j-, 

U £ MGS({<7; < A'(xi) | 1 < i < n, Xi £ dom(A')}), 

andi'^^ In , 

then (C/A",Gen(C/A",C/(To)) £ PP(M). 

4 Separate compilation 

Any separate compilation system manages a collection of small program frag- 
ments that together make up a single large program. Two questions must be 
answered by such a system. First, does the program as a whole type check? 
And second, how do we generate code for each program fragment, and how can 
we combine these code fragments into an executable program? 
We consider each of these questions in turn. 

4.1 Incremental type inference 

The problem of incremental type inference [1] can be described as follows. A 
user develops a program in an incremental fashion, by entering a sequence of 
definitions to a read-eval-print loop: 

x x = M x , x 2 = M 2 , x 3 = M 3 , . . . 

After each definition is entered, the compiler performs type inference to ensure 
the type-correctness of the partial program. Definitions may be re-defined as 
the programmer detects and corrects bugs, and they may be mutually recursive. 
Most relevant, a "bottom-up" style of program development is made possible 
by allowing definitions to refer to other definitions which have not yet been 
entered. This is exactly the strength of principal typings: type inference can be 
performed without knowing the types of free variables. 

Incremental type inference is simply the type checking task of separate com- 
pilation, on an extremely fine scale: not just every module, but every definition 
is typed and compiled separately. The type checking task can be solved elegantly 
and efficiently using principal typings. 

Consider a partial program x x = M x , . . . ,x n = M n . If a variable is defined 
twice, the latter definition takes precedence; let y x = N x , . . . , y m = N m be the 
sequence with duplicates discarded. To check that the program is well-typed, 
we can perform type inference on the expression 

(letrec y x = N x , . . . , y m = N m in 0). 

By our algorithm, type inference requires, first, computing the principal pair 
(A{, <Ji) of each (jiyiNi), and second, reconciling the type of each definition with 
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its uses. That is, if A = T,Ai, we want to satisfy the problem 
{at < A(yi) | 1 < i < m, Vi e dom(,4)}. 

We have already shown how to accomplish both tasks. 

Now suppose the user enters a brand new definition, y m +\ = N m+ \. Again, 
we must compute (Ai,<Ji) for each (jJ-yiNi). But if i ^ m + 1, then by the 
principal typing property, (Ai,<Ji) is unchanged. The principal pair for each 
definition need only be computed once, as it is entered by the user; it does not 
need to be recomputed at each new definition or re-definition. 

We must also calculate a solution to the new satisfaction problem. However, 
the new problem is almost identical to the previous problem, adding only a few 
more constraints. We may be able to incorporate large parts of the old solution 
into the new solution. Our algorithm for subtype satisfaction, described in 
Appendix B, solves problems by transforming them into equivalent, simpler 
problems until a solution is reached. Such an algorithm is ideally suited to 
incorporating parts of the old solution. The transformations that applied to 
the old problem will, for the most part, be identical to the transformations 
applicable to the new problem. 

4.2 Smartest recompilation 

Once we have solved the type checking task of separate compilation, we face the 
task of code generation. Types determine data representations, calling conven- 
tions, and other implementation details. Thus we regard compilers as functions 
from typing judgments to machine code. For example, the compilation of a 
module M that imports a module x can be written 

Compiled* : a} h M : r) = (machine code for M) . 

There are two difficulties with this strategy. First, the compiler requires as 
input a typing judgment, or, at least, the types of external variables. The 
typical solution is to require the user to supply the types. A better solution is 
available in P2, where the compiler itself can infer a judgment {x : a} h M : r 
for a term M with free variable x. 

The second difficulty arises when we need to link all of the code fragments 
together into a single program. In particular, consider recompilation, in which 
a user changes a single module x and the system attempts to recompile as small 
a portion of the entire program as possible. Certainly the definition of x must 
be recompiled. Moreover, an unchanged module M that imports x may have 
to be recompiled: if the type of 2; changes, then the typing judgment of M, and 
thus its compiled output, changes. 

This is where principal typings help. Suppose that we have compiled a 
module M by compiling its principal typing, A h M : r. At link time, we 
discover that in order to be consistent with the rest of the program, we should 
instead have compiled M by a different typing, B \- M : a. The principal typing 
property tells us that the second judgment is an instance of the first: in P2, 
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it can be obtained by substitution and subsumption from the principal typing. 
More formally, 

(B,a) = C(A,t), 

where C is an operator that applies substitution and subsumption to the pair 

Stating the problem in this way lets us study the operator C in isolation. The 
operations of substitution and subsumption specified by C can be implemented 
via coercions. These coercions can be "wrapped" around the code generated for 
the typing A h M : a at link time, making it behave like code generated for 
B\~ M :t. That is, 

Compile(5 h M : a) = Link(C, Compile^ h M : r)), 

where Link produces machine code that implements the coercions specified by C. 

Using this strategy, a module need not be recompiled unless its definition 
changes. This property was dubbed smartest recompilation by Shao and Ap- 
pel [18]. They achieved smartest recompilation for ML by relating ML to a 
restriction of P2 with principal typings. 

Shao and Appel identified the following problem with smartest recompila- 
tion. If a module references many free variables, e.g., functions from the stan- 
dard library, then the type environment of the principal typing becomes large. 
This can be alleviated in the following way. Let B be a type environment speci- 
fying the T\/2 types of our library functions. We modify our type system to use 
two type environments, so that typings are of the form 

A,B\- M : a. 

We modify our old rules to ignore this new type environment, and add a rule 
that allows us to use it: 

(var-NEw) A, B U {x : a} h x : a 

This system does not have principal typings, but it does have a useful "weak" 
form of principal typing property: given a term M typable in type environ- 
ment B, there exists a typing A, B h M : a representing all possible typings for 
Af in B. We say that M has a principal typing with respect to the type envi- 
ronment B, and that we have smartest compilation with respect to B. Since B 
only specifies types for identifiers that are relatively stable, we gain most of the 
benefits of full smartest recompilation. 

As an aside, we remark that this immediately suggests an extension to the 
type system: restore let-expressions to the language and add the rule 

A,B\-M:a, A, B x U {x : a) h N : t 
^ LET ' A, B h let x = M in N : t 

We call this a "rank 2.5" system, since it lies between ranks 2 and 3. For 
instance, it can type a term that is untypable in rank 2: 

let g = (Xx.xx) in g(Xy.y) : Vt.t — ► t. 
13 



We will not pursue this further, because we already know how to extend P2 to 
a more general system, called P, that does not rely on let-polymorphism. The 
description of P will appear in a future paper. 

We do not claim that we have solved the smartest recompilation problem 
for Standard ML. Standard ML has a rich module system, with type com- 
ponents in modules, and generative, user-definable, recursive datatypes. Our 
simple language does not support such features (nor does the work of Shao and 
Appel [18]). However, we have identified principal typings, or some equivalent, 
as the key ingredient of such a system. 



5 Error messages 

Up until now, we have concentrated on one benefit of principal typings: a term 
can be given a type without regard to the definitions of its free variables. 

The flip side of this benefit is that a definition can be typed independently 
of its uses. We now show how this allows us to produce accurate error messages 
when our type inference algorithm is faced with a program containing type 
errors. 

Consider a definition, (XxM)N, in which some uses of the variable x cause 
type errors: they require types that N cannot satisfy. To perform type inference, 
we calculate the principal typings of both the operator and the operand, say 



A h (XxM) : a 
A'Y- N : a'. 



By the principal typing property, we can calculate these principal typings in 
any order. To complete type inference, we simply check whether we can satisfy 
a' <\/2,i c- At this point we will discover all of the type errors related to x: the 
type a' will not be able to satisfy some of the constraints expressed by a. If we 
take care to label each constraint with the use of x that produced it, we can 
output the offending uses, all in one batch. 

Contrast this with the situation in ML. Assuming the definition is poly- 
morphic, we must perform type inference on a let-expression let x = N in M . 
Without principal typings, we are forced to first calculate the principal type, a, 
of N . We then process M , instantiating a at each use of x. Errors are reported 
as they are encountered, at each use. But note, the errors of one definition can 
be interspersed with errors for other definitions, or with run-on errors. And the 
type a may have been specialized for that particular (erroneous) use, leaving 
the programmer to understand a type only remotely related to the type a of 
the definition. 
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6 Does ML have principal typings? 

We have deliberately stated the principal typing property in a broad way, so 
that it can be applied to many different type systems. 3 In particular, we have 
not precisely defined what it means to represent all possible typings, because 
this will vary from one type system to another. 

This imprecision makes it impossible for us to prove that a given type system 
lacks the principal typing property. Nevertheless, we do not know of a sensible 
formulation of principal typings for ML, and in particular, ML does not have 
principal typings in the sense of our Definition 3. For example, consider the 
following ML typings of the term xx. 

{x : Vt.t} \~ xx : Vt.t, 
{x : Vt.t — ► t} h xx : Vt.t — ► t. 

Our intuition is that a principal typing EXPECTS LESS of its free variables and 
PROVIDES MORE than any other typing. We certainly cannot hope to derive a 
more general type for the term xx than (Mt.i), so the first judgment provides 
more than the second. However, the first judgment also makes a strong require- 
ment on x: the type environment indicates that it too must have type (Vt.t). 
Thus the second judgment expects less than the first, and neither typing is more 
general than the other. Moreover, there is no typing more general than both 
the typings above. The obvious candidate, 

{x : Vt.t — ► t} h xx : Vt.t, 

is not derivable. 

Why doesn't ML's principal type property imply the existence of principal 
typings? You might think that the principal typing of a term could be obtained 
from the principal type of the A-closure of the term. But ML has only a restricted 
abstraction rule: 

, , A x U {x : a] h M : r , . . . . ± . 

(ABS) A} _ / Aa , M x . a ^ T (where a is a simple type) 

In ML, we cannot abstract over variables of polymorphic type; the only way of 
introducing polymorphic variables is through let-expressions. In languages with 
a "true" abstraction rule, the principal type property and the principal typing 
property may coincide. This is the case in P2. It is also the case in rank 2 of 
System F, which lacks both principal types and principal typings [12]. 

If we want to work in a language lacking the principal typing property, 
we may still achieve some of its benefits by finding a "representation" for all 
possible typings. That is, we may relax the principal typing condition that the 
representatives themselves be typings. 

Pushed to an extreme, this is nonsense — after all, M itself is a representation 
of all typings of M\ But there is a middle ground. An example is the smartest 



In fact, we could have stated it more broadly still: we assumed typing judgments were of 
the form A h M : <r, but this is not always the case. 
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recompilation system of Shao and Appel [18]. Their type system is a restriction 
of P2. Its typings are not ML typings, but for any ML term M , there is a typing 
in their system that encodes all of the ML typings for M. Similarly, typings in 
either P2 or rank 2 of the intersection system can be regarded as the principal 
"typings" of rank 2 of System F. 

7 An extension 

The system P2 is the rank 2 fragment of a type system, P, that can type many 
more terms. The description of P is beyond the scope of this paper. However, 
we will present a few examples of its typing power. 
If we define terms M and N by 





M = (Xg. 


g(Xf.f(Xx.x))) 




N = (Xw 


w(Xy.yy)), 


wing typings hold in P: 




M 


W.((Vs.((Vm.m 


—> u) — ► s) — ► , 


N 


Vu.((Vsi.(sA( 


s^t))^t)- 


MN 


Vti -> t. 





u) —> u, 



Only M is typable in ML or P2, and only at less informative types. Note that 
in the type of M , the inner quantifier, Vw, is under the left of four arrows, well 
beyond rank 2. 

The system P has the principal typing property, decidable type inference, 
and a rule in the style of (rec) for typing recursive definitions. The crucial 
technical advance is a way of solving subtype satisfaction problems for types 
with quantifiers and intersections at arbitrary depth. 

8 Related work 

Principal typings are not a new concept. A number of existing type systems 
have principal typings, including the simply typed lambda calculus [22], the 
system of recursive types [4], the system of simple subtypes [16], and the system 
of intersection types [3]. Our contribution is to highlight the practical uses 
of the principal typing property, and to distinguish it from the principal type 
property. A number of authors have published offhand claims that ML possesses 
the principal typing property, which suggests that this distinction is not widely 
appreciated. 

The system of rank 2 intersection types is also not new, but as with the 
principal typing property, it has attracted little attention. It was first suggested 
by Leivant in 1983 [14], but he did not give a formal definition of the type 
inference algorithm or proof of correctness. In an oft-referenced 1984 paper [15] , 
McCracken gave a type inference algorithm for rank 2 of System F, inspired by 



16 



Leivant's ideas. This algorithm is incorrect. A correct algorithm for rank 2 of 
System F was finally given by Kfoury and Wells [12] in 1993. Their algorithm is 
completely unrelated to Leivant's algorithm. The earliest formal definition and 
proof of Leivant's algorithm was published in 1993, by van Bakel [20]. 

Our addition of top-level quantification is a significant technical improve- 
ment to the rank 2 intersection system, allowing a smoother development. In 
particular, the simplicity of our rule for typing recursive definitions is due to the 
power of quantifiers and the subtyping relation <\/2,i- It is possible to formulate 
an equivalent rule for typing recursive definitions without top-level quantifica- 
tion, but the machinery is cumbersome and simply duplicates the functionality 
of the quantifiers. 

We have shown that rank 2 of System F is closely related to our type sys- 
tem. However, rank 2 of System F does not have principal types or principal 
typings [12]. Launchbury and Peyton Jones [13] describe an interesting constant 
with a rank 2 System F type. Rank 2 System F types are not part of our type 
system, and we do not know how to handle their constant without resort to 
a special typing rule. This is the same solution employed by Launchbury and 
Peyton Jones. 

The system of Aiken and Wimmers [2] uses ML's let-polymorphism, and, 
therefore, we believe it does not have principal typings. The subsystem without 
let-polymorphism, though, is still of interest, and may have principal typings 
(but this is not clear). The constraint-based systems of Jones [7], Kaes [9], and 
Smith [19] are also based on ML. 

Constraint satisfaction, including subtype satisfaction, is an important com- 
ponent of each of these systems. Our method for solving constraints involving 
quantifiers (<\/2,i-satisfaction) is a significant advance over these systems. Along 
with intersections, this is the central mechanism by which let-polymorphism is 
avoided and principal typings are achieved. In our work on the system P, we 
will show how to solve some subtype satisfaction problems for types with quan- 
tifiers and intersections at arbitrary depth, giving type inference for a system 
with a much richer class of types. 



9 Conclusion 

We have shown that the principal typing property has practical applications, 
including smartest recompilation, incremental type inference, and accurate type 
error messages. Inspired by the principal typing property, we proposed a novel 
rule for typing recursive definitions. The type inference algorithm of our system 
P2 is easily extended to infer principal typings for recursive definitions under 
the new rule, resulting in a type system with decidable type inference that can 
type many examples of polymorphic recursion. 

A number of languages, including ML, seem to lack the principal typing 
property. In such languages, we may achieve some of the benefits of principal 
typings by finding a way to represent all possible typings for terms. 

Although our primary goal was to draw attention to the principal typing 
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property, a secondary contribution is to draw attention to the system of rank 2 
intersection types, which also seems to have been overlooked. Our particular 
version of this system, P2, makes an important technical contribution by show- 
ing how to solve subtype satisfaction problems for types containing quantifiers. 
Our types only have quantifiers at top level, but the method is easily extended 
to types with quantifiers at arbitrary depth, as we will show in a forthcoming 
paper. 

Acknowledgments. This paper has benefited from the comments of Assaf 
Kfoury, Albert Meyer, Jens Palsberg, and Mona Singh. 
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A Technical details of the type system 

We use x, y, ... to range over a countable set of (term) variables, and M, N , . . . 
to range over terms. The terms of the language are just the terms of the lambda 
calculus: 

M ::= x\ (M 1 M 2 ) \ (XxM). 

Terms are considered syntactically equal modulo renaming of bound variables, 
and we adopt the usual conventions that allow us to omit parentheses: appli- 
cation associates to the left, and the scope of an abstraction Xx extends to the 
right as far as possible. We write Xxi ■ ■ -x n .M for (Xxi(- ■ -(XxnM) ■ ■ •)). 

We use s,t,u . . . to range over a countable set, Tv, of type variables, and 
a, t, ... to range over types. We define several classes of types, each of which is 
a restriction of the types with quantification and intersection: 

a ::= t | (<n -► <r 2 ) | (Vi<r) | (<n A a 2 ). 

The constructor 'A' binds more tightly than '—*■', e.g., a A r — ► t means (a A 
t) —>■ t, and the scope of a quantifier 'V extends as far to the right as pos- 
sible. If t = t\, t'2, ■ ■ ■ , t n , n > 0, and a £ T2, we write (Vic) for the type 
(V<i(V< 2 (...(V<„<7)...))). 

A type environment is a finite set {x\ : ci, . . . , x n : a n } of (variable, type) 
pairs, where the variables x\, . . . , x n are distinct, and ci, . . . , <r n 6 Ti. We use A 
to range over type environments. We write A(x) for the type paired with x in A, 
dom(A) for the set {x \ 3t.(x : r) £ A}, and A x for the type environment A 
with any pair for the variable x removed. We write A\ U A 2 for the union of two 
type environments; by convention we assume that the domains of A\ and A 2 
are disjoint. We define A\ + A 2 as follows: for each x £ dom(Ai) U dom(A2), 

{A\(x) if x $ dom(A 2 ), 

A 2 (x) if x ^dom(Ai), 

A\(x) A A 2 (x) otherwise. 

We write Gen(A, a) for the V-closure of variables free in a but not A. 

B A subtype satisfaction algorithm 

A unification problem is a satisfaction problem involving only equalities. Uni- 
fication algorithms, such as Robinson's algorithm, can determine, for any uni- 
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fication problem, whether a solution exists, and, if so, produce a most general 
solution. Two problems are equivalent if they have the same solutions. 

We will show how to transform a <v 2) i-satisfaction problem into an equiva- 
lent unification problem. The transformation is defined by rules of the form 



a < t => 3s.P. 



The rules may need to introduce fresh type variables, that is, type variables 
that do not appear on the left-hand side. These variables will appear in the 
variables s of the right-hand side (but they are not the only source of variables 
in s). 

The rules are used to define a rewrite relation on problems: 



a < t => 3t.P 



3s.P' l+J {a < t} => 3s\St.P'UP 



The operator 'l+J' is disjoint union; on the right of the consequent, it means that 
the variables t must be fresh (this can always be achieved by renaming). 

The rules for transforming a <v 2) i-unification problem into a unification 
problem are given below. 



(<7l —>■ <7 2 ) < t =>■ 3tl,t 2 -{tl < <7l,<7 2 < t 2 ,t = tl —>■ t 2 } 

if t\, t 2 are fresh 

((Ti — > a 2 ) < (ti —> t 2 ) => {ti <ai,a 2 < t 2 } 

a < (ti A r 2 ) ^> {a < t± , a < r 2 } 

t < t => {t = t) 

if r is a simple type 

(Mta) <t => 3t{a < r} 

if r is not a A-type, and t is not free in r 

To see that these rules constitute an algorithm for producing an equivalent 
unification problem, observe that the rules preserve solutions, that the system 
is terminating, and that normal forms contain no inequalities, and thus are 
unification problems. 

A unification algorithm in a transformational style, taken from [8], is given 
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below. 4 

PlS{a = a} => P 

P 1+) {(Tl —>■ <7 2 = Ti —>■ T 2 } =>■ P U {(Tl = Tl, cr 2 = r 2 } 

PI±I{<1=< 2 } => {<i:=<2}i , U{<i=< 2 } 

if ti,t 2 £FTV(_P) andti ^t 2 

P l±) {t = it} => F 

[ft £ FTV(cr) and <r £ Tv 

_Pl+){t = (T } => {t :=a}P\j{t = a) 

iff £ FTV(cr), <r £ Tv, and t £ FTV(P) 

The normal forms of the rewrite system are in solved form, a set of equations 
that corresponds immediately to a most general substitution. Note the special 
problem F, used to denote failure of unification. 

The combination of these two transformation systems is an algorithm for 
finding most general solutions to <y 2) i-satisfaction problems. As a special case, 
we obtain a decision procedure for subtyping: to see whether a <\/2,i t, compute 
a member of MGS({<7 < r}) and check whether it is the identity (empty) 
substitution. 

C Typing recursive definitions in ML 

In this appendix, we show how to integrate our type inference strategy for 
recursive declarations into ML. The result is not as elegant as our rank 2 
system, but it demonstrates that an existing ML implementation could easily 
be modified to take advantage of our rules. 

To simplify our presentation we make the following assumptions, all of which 
can be relaxed without technical difficulty. We assume that no variable is bound 
more than once, and free and bound variables are distinct; and that variables 
are divided into two classes, recursive variables, which can be bound only by 
letrec and //, and ordinary variables, which can be bound by A and let. We 
use w to range over recursive variables and x to range over ordinary variables. 

We introduce a new type system with judgments of the form 

A,B\- M : a, 

where A maps recursive variables to Ti types, B maps ordinary variables to 
ML type schemes, and a is an ML type scheme. The environments A and B 
are kept separate for purposes of presentation; they might well be merged in an 
implementation. 



4 This particular unification algorithm is inefficient, because the size of the output may be 
exponential in the size of the input. It is possible to specify efficient unification algorithms in 
this style, but in order to simplify the presentation we use this more straightforward algorithm. 
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(var-REc) A U {w : a}, B h w : r (<t <i r G T ) 

, N Al){w : t},B h M : a , N 

(REC) , „ . / — —- (it y t) 

K ' A, BY- {fj,wM) :a v ; 

A U {wi : Ti, . . .,w n : T n },B h M : a 
/ tt ^„t^\ (yi<n) Al) {wi : Ti, . . .,w n : T n },B Y- (jiWiMi) : di 







A, BY- (letrecwi = Mi,. 


. . , w n = M n in M) : a 

(Vi < n,<7; >- Ti) 


(var) 




4,BU {« : a} h a; : a 




(abs) 




A,BU{x : n} h M : r 2 
A,5h (AzM) : n -► r 2 


(ri,r 2 GT ) 


(app) 


A, 


BhM:ri^T 2 A, 5 h N : 
A, BY- (MN) : r 2 


: n 


(gen) 




A,BY- M :a 


(t is not free in A or B) 


A, BY- M : (\/ta) 


(inst) 




A, BY- M : (Vtcr) 


(^T„) 


A,BY- M :{t :=r}<7 



Figure 1: A new way of typing recursive definitions in ML 
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The typing rules are given in Figure 1. The rules (rec), (var-REc), and 
(letrec) are new; all of the other rules have been taken from ML, and modified 
to handle the type environment A. Note that this system does not have the rule 
(rec-VAc); since we do not use rank 2 types, it is not necessary. 

The rules (rec) and (letrec) use a subtyping relation, y, that is the 
restriction of <\/2,i so that only ML type schemes can appear in the left position. 
It can be defined by the following rules: 

• Vic y {t := t}<7, where a and every tj is a simple type. 

• Hay T{ for all i £ I, then a y (f\ iGl t 8 ). 

Because the relation does not involve proper rank 2 types, the corresponding 
subtype satisfaction problem can be solved more easily than the general case. 
The problems are of the form 3s. P, where P is a set of equalities between 
simple types and inequalities (a y r) between ML type schemes and Ti types. 
The following rules are sufficient to transform such problems into equivalent 
unification problems. 

a y t => {a = t} 

if a, t £ T 

a y (ti A r 2 ) =>■ {a y Ti,a y r 2 } 

(Vta) y t => 3t{a y t} 

if r is not a A-type, and t is not free in r 

To find U £ MGS(-7r), use the rules to transform 7r into ir' with only equalities, 
and then use unification on ir' to find U . 

Now we consider how to perform type inference. The type inference algo- 
rithm W* of Shao and Appel [18] can easily be extended to this system. But 
most compilers are based on Milner's algorithm W , so we use W as a starting 
point. 

The modified algorithm, called W' , is given in Figure 2, and it behaves as 
follows. If W'(B, M) = (A, S, t) , the principal typing of M with respect to B 
is 

A,SBh M : Gen(A,SB,r). 

Note that we have extended the operator Gen so that Gen(A,B,a) is the V- 
closure of a by type variables that do not appear free in A or B. To simplify our 
presentation, we have only considered the case of letrec expressions that define 
exactly two variables. The general case introduces no technical difficulties. 
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W'(B,M) = case M of 

w =>■ let t be a fresh type variable 

in ({w:t},{},t) 

{nwM-i) => let (A,5,r) = W(Mi) 

in if w ^ dom(j4) then (A, 5, t) 
else let a = Gen(j4, SB, r) 

C/ e MGS({<7 y A(w)}) 
Wt' = Ua 

s be fresh type variables 
in (UA w ,US,{t:=s}T'} 

(letrec w 1 = M 1 , w 2 = M 2 in M ) 

=> let (A ,S ,T ) = W'(B,M ) 

(A^Sun) = W'(S B,(fiw 1 M 1 )) 
(A 2 ,S 2 ,t 2 ) = W'iSiSoB, (}iw 2 M 2 j) 
A = S 2 S 1 A + S 2 A 1 +A 2 
S = S 2 SiSo 
<7i = Gen(j4, 55, 5 2 ti) 
a 2 = Gen( A, SB, t 2 ) 

U e MGS({<7,- >- A(iu,-) I i £ {1,2}, Wi £ dom(,4)}) 
in (W Wl)ffi2 , ?75, t/5 2 5iT ) 

a; =>• if x (fi dom(B) then fail 

else let Vtr = 5(«) 

s be fresh type variables 
in ({},{}, {t:=s}r) 

\xM\ =>• let t be a fresh type variable 

(A,S,t) = W'(BU{x :t},Mi) 

in (A, 5, 5* -► r) 

MiM 2 => let (Ai,5i,ri) = W r/ (B,Mi) 

(A 2 ,5 2 ,r 2 ) = W r, (5i J B,M 2 ) 
t be a new type variable 
5 3 G MGS({5 2 T! = t 2 -^ t}) 
in (SaSaAi+SgAa.SaSaSi.Sa*) 

let a; = Mi in M 2 

=> let (Ai,5i,ri) = W r, ( J B,Mi) 

(A 2 , 5 2 , r 2 ) = W(5i5 U {x : Gen(A u 5i5, n)}, M 2 ) 
in (5 2 Ai + A 2 ,5 2 5i,r 2 ) 

Figure 2: Extending ML's type inference algorithm for recursive definitions 

25 



